The present invention relates to communication networks, and, more particularly, to fault detection in multiprotocol label switching (MPLS) networks.
MPLS is a core technology for deploying connection-oriented services over a non-heterogeneous network. In an MPLS network, incoming packets are assigned a label by a label edge router (LER). Packets are forwarded along a label switch path (LSP) by label switch routers (LSRs), which make forwarding decisions based on the labels assigned to the packets. An LSP is a unidirectional connection between two MPLS edge devices and may be used by network operators, for example, to guarantee a certain performance level or quality of service, to create routes around network congestion, and/or to create tunnels for virtual private networks (VPNs).
An LSP may be bound to a particular set of nodes and links using explicit routing. As in any network, various components of an MPLS network, e.g., nodes, links, etc., are subject to failure. When a component in an explicitly routed LSP fails, traffic is no longer passed along the LSP to its destination. Failure detection and correction techniques are therefore applied to LSPs inasmuch as LSPs are typically not fault tolerant and/or self-correcting. In general, there are two types of fault detection and/or correction methodologies that may be used to maintain the reliability of LSPs: 1) path protection and 2) segment protection. Path protection is based on an ingress node monitoring the status of an LSP and switching to an alternate LSP or communication path upon detecting a failure. Segment protection is based on nodes in the LSP monitoring the status of links that connect them to the MPLS network and switching to an alternate link upon detecting a link failure. In general, most of the LSP path is maintained and only a short detour around the failure is typically required. The endpoints of the LSP typically need not be notified of the detected link failure.
Referring now to FIGS. 1A-1C, a conventional fault detection technique for providing path protection in an MPLS network will now be described. At block 100, an ingress node periodically transmits an LSP echo request packet to an egress node using an LSP. Upon receiving the LSP echo request packets, the egress node transmits an LSP echo response packet back to the ingress node at block 105 of FIG. 1B. Note that an LSP is a unidirectional connection. Therefore, the egress node may use an LSP or a non-LSP path to communicate the LSP echo response packet to the ingress node. The ingress node receives any LSP echo response packets from the egress node at block 110 and determines at block 115 whether it has received a sufficient number of LSP echo response packets back from the egress node based on the number of LSP echo request packets it has transmitted. For example, the ingress node may determine whether the number of LSP echo request packets that it has transmitted exceeds a number of LSP echo response packets it has received back from the egress node by a threshold value. If the ingress node does not receive a sufficient number of responses to its “pings” of the egress node, then the ingress node assumes that there is a fault in the LSP to the egress node or that there is a fault in the return path from the egress node to the ingress node.
To isolate the source of the fault, the ingress node transmits an LSP echo request packet with a downstream mapping TLV to each of the transit nodes along the path to the egress node using the LSP at block 120. The downstream mapping TLV can be used to isolate an LSP failure point within the MPLS network. In response to an LSP echo request packet with a downstream mapping TLV, a transit node transmits an LSP echo response with an indication whether it is a valid downstream LSR for the LSP at block 125 of FIG. 1C. The ingress node correlates the LSP echo response packets with downstream mapping type-length-values (TLVs) it has received from the transit nodes at block 130 and isolates the LSP failure point at block 135. Failure recovery may be invoked to restore service; otherwise, the ingress node determines that the fault was in the response path from the egress node to the ingress node.
Unfortunately, the fault detection approach illustrated in FIGS. 1A-1C is dependent on end-to-end support of the draft LSP Ping protocol and is currently not applicable to LSPs created manually.